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Abstract 


This document describes a meeting location policy for the IETF and the various stakeholders 
required to realize this policy. 


Status of This Memo 


This memo documents an Internet Best Current Practice. 


This document is a product of the Internet Engineering Task Force (IETF). It represents the 
consensus of the IETF community. It has received public review and has been approved for 
publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is 
available in Section 2 of RFC 7841. 


Information about the current status of this document, any errata, and how to provide feedback 
on it may be obtained at https://www.rfc-editor.org/info/rfc8719. 


Copyright Notice 


Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights 
reserved. 


This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF 
Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this 
document. Please review these documents carefully, as they describe your rights and restrictions 
with respect to this document. Code Components extracted from this document must include 
Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are 
provided without warranty as described in the Simplified BSD License. 
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1. Introduction 


The work of the IETF is primarily conducted on working group (WG) mailing lists, while face-to- 
face WG meetings mainly provide a high-bandwidth mechanism for working out unresolved 
issues. The IETF currently strives to have a 1-1-1 meeting policy where the goal is to distribute 
the meetings equally between North America, Europe, and Asia (see "Meeting Location 
Distribution" (slides 14 and 15) of [[ETFMEET] for details). These are the locations from which 
most of the IETF participants have come in the recent past. This meeting rotation is mainly 
aimed at distributing the travel effort for the existing IETF participants who physically attend 
meetings and for distributing the timezone difficulty for those who participate remotely. This 
policy has been neither defined precisely nor documented in an IETF consensus document until 
now. This BCP RFC is meant to serve as a consensus-backed statement of this policy. 


2. The 1-1-1-* Meeting Policy 


Given that the majority of the current meeting participants come from North America, Europe, 
and Asia [CONT-DIST], the IETF policy is that the meetings should primarily be held in those 
regions. That is, the meeting policy (let's call this the "1-1-1" policy) is that meetings should rotate 
between North America, Europe, and Asia. Note that the boundaries between those regions have 
been purposefully left undefined. It is important to note that such rotation and any effects to 
distributing travel pain should be considered from a long-term perspective. While a potential 
cycle in an IETF year may be a meeting in North America in March, a meeting in Europe in July, 
and a meeting in Asia on November, the 1-1-1 policy does not imply such a cycle, as long as the 
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distribution to these regions over multiple years is roughly equal. There are many reasons why 
meetings might be distributed differently in a given year. Meeting locations in subsequent years 
should seek to rebalance the distribution, if possible. 


While this meeting rotation caters to the current set of IETF participants, it is important to 
recognize that due to the dynamic and evolving nature of participation, there may be significant 
changes to the regions that provide a major share of participants in the future. Therefore, the 
1-1-1-* meeting policy is a slightly modified version of the aforementioned 1-1-1 meeting policy 
that allows for additional flexibility in the form of an exploratory meeting (denoted with an "*"). 
Exploratory meetings can be used to experiment with exceptional meetings without extensively 
impacting the regular meetings. For example, these exploratory meetings can include meetings 
in other geographical regions, virtual meetings, and additional meetings beyond the three 
regular meetings in a calendar year. 


The timing and frequency of future exploratory meetings will be based on IETF consensus as 
determined by the IETF chair. Once a meeting proposal is initiated, the IESG will make a decision 
in consultation with the IETF Administrative Support Activity (IASA) [RFC8711] to ensure that the 
proposal can be realistically implemented. The final decision will be communicated back to the 
community to ensure that there is adequate opportunity to comment. 


NOTE: There have not been a large number of meetings that would qualify as 
exploratory meetings under the 1-1-1 policy (with IETF 95 in Buenos Aires and IETF 
47 in Adelaide being the exceptional instances). IETF 27 (Amsterdam) and IETF 54 
(Yokohama) were earlier examples of exploratory meetings that pioneered Europe 
and Asia as regular IETF destinations. 


3. Implementation of the Policy 


IASA should understand the policy written in this document to be the aspiration of the IETF 
community. Similarly, any exploratory meeting decisions will also be communicated to the IASA 
to be implemented. The actual selection of the venue would be performed by the IASA following 
the process described in [RFC8718]. 


As mentioned in [RFC8718], the IASA will also be responsible for the following: 


e assisting the community in the development of detailed meeting criteria that are feasible 
and implementable, and 

e providing sufficient transparency in a timely manner concerning planned meetings so that 
community feedback can be collected and acted upon. 


Given that the geographical location of the venue has a significant influence on the venue 
selection process, it needs to be considered at the same level as the other Important Criteria 
specified in Section 3.2 of [RFC8718] (including potentially trading-off the geographical region to 
meet other criteria and notifying the community if the geographical region requirement cannot 
be met). 
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4. Procedure for Initiating Proposals for Exploratory Meetings 


Someone who is interested in pursuing an exploratory venue proposes it on the IETF discussion 
list or on a future discussion list expressly set up and announced for this purpose. The 
community gets to comment on the venue and offer their opinions. If the IETF chair determines 
that there is community consensus to pursue the venue further, the venue will be put up for 
discussion on the venue-selection mailing list <https://www.ietf.org/mailman/listinfo/venue- 
selection>. This would allow the interested party(ies) to refine their proposal based on insightful 
feedback regarding the logistics of the venue from those tasked with evaluating it. Once the 
venue selection process takes place, the final decision will be communicated back to the 
community to ensure that there is adequate opportunity to comment. 


5. Re-evaluation and Changes to This Policy 


Given the dynamic nature of participant distribution in the IETF, it is expected that this policy 
will need to be periodically evaluated and revised to ensure that the stated goals continue to be 
met. The criteria that are to be met need to be agreed upon by the community prior to initiating a 
revision of this document (e.g., try to mirror draft author distribution over the preceding five 
years). 
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